home *** CD-ROM | disk | FTP | other *** search
Text File | 1991-03-06 | 3.8 KB | 113 lines | [TEXT/GEOL] |
- Item 8685373 25-Feb-90 14:11PST
-
- From: GER.XDV0002 Germany - P1 Ges f Informatik,IVR
-
- To: MACAPP.TECH$ MacApp Technical
-
- Sub: Combined purge and dehydrate!
-
- I am following the "persistent" discussion with great interest via the weekly
- summaries. I am not a member of MACAPP.TECH$ (too much incoming mail) and
- therefore the following proposal may be already a little bit out of date.
-
- During reading Greg's paper "persistence (longish)" I had the following idea:
-
- I think we can handle "purged" objects nearly as "dehydrated" objects and
- combine both advantages!
-
- The compiler does not need a valid object handle to call a method! The first
- dereferencing of an object handle is only done either in the method dispatch
- routine (polymorphic methods) or inside the called method (optimized
- monomorphic methods).
-
- The method dispatch routine can be patched to test for an odd handle (used as
- indication that the handle is no handle but an object ID) and call a routine
- which delivers the needed class ID for purged objects. This routine should also
- read in the object and replace the object ID by the object handle.
-
- The first call inside the method must be "Lock (SELF)" if objects of this class
- may be dehydrated or purged. Lock has to test for the three possible states of
- an object:
- 1) loaded:
- SELF is the normal object handle:
- Nothing to do.
- 2) dehydrated:
- SELF is a valid handle, but points only to the dehydrated information:
- The object must be read in by using the dehydration info.
- 3) purged:
- SELF is an object ID (e.g. indicated by an odd value):
- The object cache must be used to read in the object and SELF must be
- replaced by an object handle value. As SELF cannot be passed as a VAR
- parameter to Lock we need some knowledge of the generated code of the
- compiler (note the generic name, there are others than Object Pascal and
- I am not thinking at C++!) but this is easy because the implicit SELF
- parameter has always the same frame offset ("8(A6)" in Object Pascal and
- Modula-2).
-
- A similar classification will apply to classes:
- 1) standard:
- All objects are always loaded.
- 2) dehydratable:
- Objects may be dehydrated but not purged:
- All methods must have a call to Lock as first statement.
- 3) purgable:
- Objects may be dehydrated or purged:
- All methods must have a call to Lock as first statement and all
- references to objects of these classes must use object IDs.
- For both dehydratable and purgable classes references to object fields are only
- allowed after a call to Lock, but preferable they should be encapsulated in
- methods.
-
- Lock can be even a parameterless method of TObject but overriding it must be
- done with care because the inherited call of Lock will only replace the object
- ID in the calling Lock method but not in the method which called Lock. To do
- this there would be needed a procedure (method?) "UpdateSELF" to replace the
- object ID by SELF in the method above (two stack frames above from inside
- UpdateSELF). These last ideas may be a little bit confusing and superfluous but
- they show the flexibility of such an approach.
-
- Unlock should be a parameterless method of TObject with an empty
- implementation. By overriding Unlock you can then decide whether the object
- should be dehydrated or purged. Unlock must be called at the end of each method
- which calls Lock.
-
- The overhead for this solution is very limited, for loaded objects of standard
- classes it is only one additional test in the method dispatch routine.
-
-
- Please send a copy of any direct comment to my AppleLink address (GER.XDV0002)
- then I have not to wait for the next TECH$ summary. Thank you.
-
- Elmar Henne
- p1 GmbH, Munich
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-